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ANNOUNCED SESSION CONTROL 



The present invention relates to the announcement and subsequent management of media 
stream connections for a media session over a communications network. 

Multicast transmissions are becoming increasingly common on the Internet. In contrast to 
standard Internet Protocol (IP) point to point transmissions (unicast), IP multicast allows 
the simultaneous transmission of information to a group of recipients from a single source. 
Routing support for IP multicast transmissions is provided by the MBone (IP Multicast 
Backbone) which is a virtual network layered on top of the Internet. 

IP multicast allows real-time communications over wide area IP networks and typical 
transmissions include video and audio conferencing, live multimedia training, university 
lectures and transmission of live television programmes. 

A multicast transmission usually consists of a multimedia session made up of several 
individual media streams typically carrying video, audio, whiteboard or raw data. Some 
sessions are persistent, but the majority exist for a specific period of time, although need 
not be continuous. Multicast based transmissions on the MBone differ from unicast IP 
transmissions in that any user receiving the transmission can join the session (unless the 
transmission is encrypted) . and to receive a transmission, a user need only know the 
appropriate transmission address and timing information. 



An example of an IP multicast transmission system is described with reference to Figure 1. 



Prior to a multicast transmission, an appropriate announcement containing a session 
description is made/thereby allowing end users HOa-llOe to elect to receive the 
transmission. Each end user electing to receive the transmission is linked to a group IP 
Multicast address 120 associated with the transmission. At the transmission time of the 
multicast session, the session streams are transmitted from a source 130, or a plurality of 
sources, to the group address. At the group address, the transmission is disseminated along 
the links 140 to those end users who have elected to receive it (in this example end users 
110a- 110c). 



An example of a conventional announcement and election system currently used is 
described with reference to Figure 2. Most public multicast sessions are announced at a 
single group IP multicast address 200 dedicated to the transmission of announcements to 
multicast end users. End users 210a-210e electing to receive the announcements are linked 
to the announcement group address and, in the same way as an actual session transmission, 
each announcement arriving at the announcement group address is disseminated to the end 
users. A front end interface 220 on each end user's computer displays information obtained 
from the associated session description for each announcement. The minimum information 
a session description must contain is a time and date that the session will be active and the 
group IP muhicast addresses) from which the end user may elect to receive one or more 
media streams and to which they could send their own streams for the session. Using the 
front end interface, an end user can select the announced session(s), or their component 
stream(s) they wish to participate in and the interface then sets up the necessary links to the 
one or more group IP multicast addresses through an associated multicast multimedia 



application. 



Standard session descriptions are generated using a Session Description Protocol (SDP), as 
defined in the Interne. Engineering Task Force's draft RFC 2327. SDP is a simple ASCII 
text based protoco! that is used to describe reai time multimedia sessions and their related 
scheduling information. SDP messages are wrapped in a carrier protocol, known as a 
Sesston Announcement Protocol (SAP), which, in addition to containing the necessary IP 
addressing and routing information for transmission across the Internet or MBone, allows 
the SDP message to be encrypted, signed or compressed. An announcement can then be 
sen, a. regular intervals to the announcement group address. As an alternative to SAP, a 
session may be announced by placing an SDP message on a World Wide Web site (WWW) 
or by sending i, to individuals by email or as a unicast transmission inviting them to 
participate. 



An SDP message conveys information about each media stream in the multicast multimedia 
sesston to aUow the recipients to participate in the session. A typical SDP message wil, 
include the sesston name and purpose, the ttae(s) and date(s) the session will be active, the 
component media streams of the session and information required to participate in each 
media stream (IP multicast address, port, media format). The SDP message may also 
include details of the session's bandwidth requirements, an encryption key necessary to 
participate in a secure multicast transmission using public key encryption, contact 
information for the organiser of the multicast sess.on, and a Unique Resource Indicator 
(URI) pointing to a WWW or an Intranet web site where further information on the session 



may be found. 



The level of participation a user may make in a session or stream depends on its purpose. 
In a multicast television session, typically users would only be able to receive the session 
streams whilst in a multicast conference session the communication would be bi-directional 
with a central server (such as group address 120) receiving each participants transmissions 
and relaying them to the other participants. The level of participation expected of a user in 
a session or stream may be explicitly stated in the session description or it may be inherent 
from the session description, for example when a receive-only application is associated 
with a media stream type in the session description. 

A common front end interface used by multicast end users is known as Session Directory 
Rendezvous (SDR). This interface takes the received announcements, decodes the SDP 
message and displays the names of those sessions that are still current in a list. The end 
user may then select one of the listed announcements to view further .technical and user- 
- oriented details of the announced session. From the displayed information, the end user 
can then select to join individual streams of the session or to join the entire session. Once 
the streams to be joined are selected, SDR starts the necessary multicast-enabled 
multimedia application on the end user's computer, such as Vic and Vat, and passes the 
relevant stream information (a transport port address) from the announcement onto the 
application allowing the application to establish the link to the associated IP multicast 
address and participate in the stream at transmission tune. Having initiated the applications 
SDR plays no further part in the session. 
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Recent increased usage ana demand for (muM)media sessions has highlighted a number of 
.imitations ,„ SDP. SDP limits se s sion descriptions to defining a session having a single set 
of timings that appiy to ail of the streams within it. A session in which a stream starts mid- 
way through the transmission cannot easily be described using SDP. The structure of a 
5 session description written in SDP must be a simple linear lis, „, streams which may no, 
reflect me intuitive structure of a compiex session. SDP supports a limited and predefined 
set of applications which can receive the streams and a limited and predefined se, of 
Tanspor, mechanisms (e.g. Simp,e layering, RTF and UDP). As guaranteed Quality of 
Service (QoS) is becoming more and more desirable to the consumer and the supplier, the 
.0 need ,o define QoS polices for the entire session and individuai streams in terms of 
required system resources, bandwtdth requtrements and supported applications aiso needs 
«o be met. There may also be requirements on the prioritisation of streams and subsessions 
or more compiled ruies about receiving streams. A further requirement on me par, of 
the suppiier win be the need for charging faclities permitting the charging of an end user 
5 for a muhicas, transmission ,o which drey subscribe according ,o ,he QoS and types of 
s,reams received e,c. There is little scope to include information about QoS poiicies or 
charging withm the conventional structure of an SDP session description, or any metadata 



about the session. 



20 According to a firs, aspect of the present invention, a method of announcing a description 
of a media session, comprises the steps of generating a first base module containing user 
orientated data relating to the media session, generating « Ieast one mcdia module 
containing technical data necessary for a user to receive a media stream of the media 



session, linking the first base module to the at least one media module, and announcing the 
media session by making at least the first base module available to potential recipients of 
the media session, wherein the link between the first base module and the at least one 
media module permits a party to access the at least one media module and subsequently 
participate in the media session. 

Preferably, the method further comprises the steps of generating a second base module, the 
second base module containing user orientated data relating to a sub-session of the media 
session, linking the second base module to the first base module, generating at least one 
media module, and linking said at least one media module to the second base module. 

A media module may prescribe the application to be used to participate in the media 
session. A media module may prescribe a number of application components to be used in 
order to build an application to participate in the media session. The media module may 
prescribe a manner in which the components are to be configured to build the appl: 
A media module may declare a number of requirements which an application 
configuration of application components must satisfy in order to be used to participate 



lication. 



or a 



m 

the media session. 



According to a second aspect of the present invention, a computer readable storage 
medium contains data defining at least a part of a description of a media session, the 
session description comprising a first base module containing user orientated data relating 
to the media session, wherein the first base module includes a link to at least one media 



module W hich provides techmcal data necessary for a user ,o receive a media stream of the 
media session, and wherein the link between the first base module and the a, leas, one 
media module permits a party to access the a. least one media module and subsequently 



receive the media stream. 



A media module may prescribe the application to be used to participate in the media 
session. A media module may prescribe a number of application components to be used to 
build an application to participate in the media session. The media module may prescribe a 
manner in which the components are to be configured to build the application. A media 
module may declare a number of requirements which an application or a configuration of 
application components must satisfy in order to be used to participate in the media 



session. 



The present invention provides a modular description system for a media session in which 
session description, are constructed in a tuerarchical manner providing a plurality of levels 
of information concerning the constituent parts of the described session. 

A problem faced with the current distribution of announcements from the single 
announcement group address is that there is a limit to the size of each announcement and 
the frequency with which each can be sent out. In the present invention, it is possible to 
provide a modular description system in which a distributed announcement contains links 
available to the end user to other portions of the announcement which have not been 
transmitted. 
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Another problem faced by providers of current (multi)media sessions and the developers of 
the associated (multi)media applications is the spread of skills required to implement an 
application that can initiate and manage a real-time data connection over a communications 
network and perform the (multi)media functions the end user would expect. Furthermore, 
until now the only way a QoS policy could be implemented was to process a session 
description to determine which streams of a sess,on could or should be run and then to 
initialise the applications so they connect to the respective streams. This required the 
communications manager not only to know about the session requirements and available 
system resources but also the capabilities of each application. 

According to a third aspect of the present invention, a method of managing media stream 
connections for a media session, having obtained a session description of the media session 
at a terminal, comprises the steps of parsing the session description using a terminal 
session control system to determine one or more applications for the or each media stream 
of the session description needed to support the media session, selecting one or more 
media streams identified in the session description and subsequently initiating the one or 
more media streams so that the or each media stream can subsequently be received by the 
terminal, wherein the session control system manages the connections required to 
participate in the media session. 

The applications may select one or more of the media streams identified in the session 
description which are required and pass a number of connection requests to the session 

control system. 



The step of parsing the session description may include the steps of determining 
application configurations to satisfy requirements identified in the session description to 
participate in the media session. 

Preferably, the terminal session control system parses the session description and passes at 
least a portion of the session description to an application builder for determining the 
application configurations. Preferably, the application builder builds the application(s) 
necessary to participate in the media session. The application builder may generate or 
modify a quality of service policy for the connection request for use by the terminal 
session control system. The application builder may modify the session description for 
changing the subsequent management of connections by the terminal session control 
system. Preferably, the application is built from a number of application components. 

According to a fourth aspect of the present invention, a system for managing media stream 
connections derived from a session description of a media session, comprises a session 
control system for parsing the session description to determine one or more applications for 
the or each media stream of the session description needed to support the media session, the 
session control system being arranged to manage connections required to receive the one or 
more appropriate media streams of the media session. 

Preferably, the session control system further comprises means for determining application 
configurations to satisfy requirements identified in the session description to participate in 



the media session. 
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Preferably, there are a number of application components from which the application 
configurations are determined and from which the applications are built. 



Preferably, an application builder builds the applications. 



In a preferred example of the present invention the media modules of a session description 
are checked by the respective multimedia client application prior to QoS management, 
thereby reducing the workload of the communications manager. Furthermore, applications 
need only request streams from the session control system since this is now handles 
centrally the creation and management of streams in real time. 

The present invention simplifies application development and service provision. A further 
problem is that applications should be able to adapt to available network and host 
resources. This is particularly important for multi-party applications operating in 
heterogeneous environments where each party may have different resources available to 
them. Furthermore the nature of the heterogeneity may vary over the lifetime of the 
session, for example as network congestion varies or as the terminal resources are shared 
with other applications or other users. The present invention is able to use a QoS policy 
incorporated within the session description to prioritise the allocation of resources and to 
determine whether participation in the session is viable. 
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A still further problem is that the application developer and service provider typically need 
to address security and charging requirements. The present invention allows security and 
charging policies to be incorporated within the session description for use within the 
session control system to invoke appropriate charging and security procedures. Instead of 
having to develop security and charging functions the application developer and service 
provider need only specify appropriate policies. 

In the present invention application development is simplified by using the session 
description to drive the dynamic management of communication channels and to adapt to 
available resources. It also reduces the problem of handling charging and security 
requirements to a matter of specifying charging and security policies within the session 
description. 

Examples of the present invention will now be described in detail with reference to the 
accompanying drawings, in which: 

Figure 1 is a schematic diagram illustrating a multicast transmission across the MBone; 
Figure 2 is a schematic diagram illustrating the distribution of an SDP announcement; 
Figure 3 is a block diagram of a modular session description of a simple session generated 
in accordance with the present invention; 

Figure 4 is a block diagram of a modular session description of a complex session 
generated in accordance with the present invention; 

Figure 5 is a schematic diagram of a system for managing media stream connections; 
Figure 6 is a flow chart illustrating the steps involved in managing a media session 
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according to the system of Figure 5; 

Figure 7 is a flow chart further illustrating a parsing step of Figure 6; and, 

Figure 8 is a schematic diagram of another system for managing media stream connections 

at a terminal in accordance with the present invention. 

Figure 3 is a block diagram of a session description 300 for a simple multicast television 
session. The session description 300 comprises a base module 310 linked to a media 
module 320. 

The base module 310 contains user oriented data relating to the session including the title 
and timing information. The base module 310 may also include a description or abstract, 
contact information about the organiser and a WWW or an intranet URI pointing to a web 
site containing further information. Ideally, the base module 310 should contain enough 
information for the user to decide if they are interested in participating in the session. 

The media module 320 contains announcement data relating to a video stream of the 
session. The media module 320 contains the technical information (data) necessary for the 
user to receive the associated media stream. In particular, connection, timing and media 
format details are provided. 

A first example of a session description 300 generated for transmission to end users is 
shown below: 
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( 

type = (base) 
id = (310) 

info = (title = "live multicast television session") 

source = (name = "A.Sender" email = asender@tx.com) 

media = (video = (client = odbitsO . 1 6)) 

time = (length = 50m repeat = continuous) 

category = ("Entertainment") 

options = (none) 

modules ==(m= 320) 

) 

( 

type = (media) 
-> id = (320 310) 

media = (video = (client = odbitsO. 1 6)) 
connection = (229. 1 . 1 .2/7000) 
time = (length = 50m) 
) 



Session description example 1 

The base module 310 has a unique identifier (id field) used in the generation of links 
between two modules during the processing of the session description. The modules field 
of the base module 310 lists the type and unique identifier of the media module 320 linked 
to the base module 310. The second identifier in the id field of the media module 320 is 
the unique identifier belonging to the base module 310 linking the media module back to 
the base module 310. By extension, these two-way links permit a module tree to be 
traversed from a base module downwards or from a media module upwards. The use of 
this feature is described later with reference to session description example 4. 

The connection field of the media module 320 contains the IP multicast address and port 
number from which the media stream can be received. 

Figure 4 is a block diagram of a session description 400 for a complex multicast session of 
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a multimedia conference with two tracks and a panel discussion. Each track provides 
multiparty video and audio conferencing and a shared whiteboard for leaving notes and 
messages. The panel discussion is encrypted and the whole conference is subject to a 
subscription fee payable in advance by each participant. 

The session description 400 contains a top level base module 410 linked to further base 
modules 420, 430, 440 and an options module 411. The top level base module 410 
contains data relating to the overall session including its name, purpose and timing 
information. The options module 411 contains details of the payment mechanism for 

subscription fees. 

Each further base module 420, 430, 440 relates to a subsession of the conference. Base 
module 420 relates to the first track of the conference. The base module 420 is linked to 
media modules 421-423, each containing connection, timing and media format data for 
respective video, audio and whiteboard streams. 

The base module 420 is also linked to options module 424 which contains data relating to a 
QoS policy for the first track defining which media modules are optional and which are 
mandatory for a participant of the first track. The mandatory list contains identifiers of 
those media modules which are needed for the session or subsession to operate correctly 
whilst the optional list contains identifiers of the media modules that are not necessary for 
the session or subsession to operate correctly if system resources are scarce. 
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The base module 430 relates to the second track of the conference. It is linked to media 
modules 431-433, each containing connection, timing and media format details for 
respective video, audio and whiteboard streams. The base module 430 is also linked to 
options module 434 which contains data relating to a QoS policy for the second track 
defining which media modules are optional and which are mandatory for a participant of 
the second track. Base module 440 relates to the panel discussion. It is linked to media 
modules 441 and 442, each containing connection, timing and media format details for 
respective video and audio streams of the panel discussion. The base module 440 is also 
linked to options module 443 which contains encryption details (i.e. how and where to get 
the necessary cryptographic keys) necessary for a participant to decode the panel 
discussion media streams 441, 442 according to a known encryption mechanism such as 
DES or public key encryption. 

The video media stream defined in media module 441 is layered. Layering of media 
streams allows users with different system resources to receive as much of the stream as 
their system resources allows. Every user must receive the bottom layer of the stream 
containing the minimum stream data. However, if a user has sufficient free system 
resources they can receive the next layer up containing enhancements to the previous layer. 
Successive layers can be received enhancing the received media stream until the maximum 
number of layers is received or all free system resources capacity is used. The media 
module 441 is linked to an options module 444 which contains data on the layering 
necessary for the end user to be able to receive the layered stream correctly. 
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The portion of the session description 400 generated for modules 410, 411, 
transmission to end users is shown below in session description example 2. 



( # overall conference session 
type = (base) 
id =(410) 

info = (title = "Multimedia98 Conference") 
source = (owner="Joe Bloggs" email = joe@nowhere.com) 
media = (video = (client = RealPlayerG2) whiteboard = (client = wb)) 
time(start= "09:00 GMT 25/12/98" stop="13:00 GMT 25/12/98") 
options = (oc =411) 
> modules = (b= 420 b=430 b=440 oc=411) 



( # conference track 1 
type = (base) 

+ id = (420 410) 

info = (title ="MM98 Systems and Applications Track") 
sources (owners "Joe Bloggs" email = joe@nowhere.com) 
media = (video = (client = RealPlayerG2) whiteboard = (client = wb)) 
time(start=** 09:00 GMT 25/12/98" stop* "11:00 GMT 25/12/98") 
options = (osq= 424) 

► modules = (m = 42 1 m = 422 m = 423 osq =424) 



# session QoS for track 1 
type= (option-sQoS) 
id = (424 420) 
mandatory = (421 422) 
optional = (423) 



( # conference panel discussion 
type = (base) 
^ id = (440 410) 

info = (title ="MM98 Panel Discussion") 

source = (name = "Joe Bloggs" email = joe@nowhere.com) 

media = (video = (client = RealPlayerG2) whiteboard = (client = wb)) 

tirne(start= "11:00 GMT 25/12/98" stop="13:00 GMT 25/12/98") 

options = (osec - 443) 

> modules = (m= 44 1 m=442 osec =443) 
) 

( # video for panel discussion 
type = (media) 

> id = (441 440) 

info = (title ="MM98 Panel Discussion Video") 
source = (owner = "Joe Bloggs" email = joe@nowhere.com) 
media = (video = (type = live client = RealPlayerG2)) 
connection = (226 . 0 . 0 . 1 06/ 1 0 1 0 policy = 444) 
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= (start= " 1 1 :00 GMT 25/12/98" stop= "13:00 GMT 25/12/98 



( # media QoS policy for panel discussion video 
type= (option-mQoS) 
> id = (444 440) 

mechanism = (layer=(base = 226.0.0.106/1010 number = 3)) 



( # encryption policy for panel discussion 
type = (option-sec) 
id = (443 440) 

participant = (member = w3c) 

publickey = (location=http://www.w3.org/members only/) 
mfo = (location = http : //www . w3 . org/) 



( # charging policy for entire conference 

type = (option-chg) 
> id = (411 410) 

mechanism = (type = AAA) 

price = (fee = 1 000GBP) 
^ info = (location = http : //www . aaa . net/) 

Session description example 2 



Where there is surplus network bandwidth available, complete session descriptions can be 
announced to end users who may then elect to receive the announced session or parts 
thereof. However, the individual modules of the session description do not need to be 
announced together. If the network bandwidth available for announcements restricts the 
size of session descriptions, only the top level base module may be announced. In this 
situation, the link between modules may be a URI to a WWW or an intranet web site or 
server, an email address, an IP multicast address, an FTP address or details of a file or 
database stored on a local computer system from which an interested user can obtain the 
remaining modules. 
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15 
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The following session description example illustrates how the above session description for 
base module 420 would be changed if media module 421 was stored on a WWW 



server: 



( # conference track 1 
type = (base) 
id = (420 410) 

info = (title = "MM98 Systems and Applications Track") 
source = (owner = "Joe Bloggs" email =joe@nowhere.com) 
media = (video = (client = RealPlayerG2) whiteboard = (client = wb)) 
ume(start= "09:00 GMT 25/12/98" stop="ll:00 GMT 25/12/98") 
options = (osq= 424) 

modules = (m=421 location =http://ww. announce. org/cgi-bin/rnodule.cgi'>id = 421 
m=421 m = 423 osq=424) 

Session description example 3 



Furthermore, top level modules of a session description may be announced well in advance 
of the actual transmission, at a time where the final details of content are unknown, in 
which case the remaining levels may be made available from pre-announced links at a later 
20 time. 

Figure 5 is a schematic diagram of a system for managing media stream connections at a 
terminal of an end user system according to the present invention. 

25 The session control system 500 is linked to an announcement receiving interface 510 and 
one or more multicast-capable multimedia applications 520. The session control system 
500 and the announcement receiving interface 510 are connected to a network interface 
530 via which announcements may be received and multicast transmissions may be 
initiated and/or received. 
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Announcements received a, ,he network interface 530 are routed to the receiving interface 
510. The receiving interface 510 decodes each announcement to obtain the session 
description and disp,ays the user oriented mformation from the one or more base modules 
in a list to the user. The user is able to select a session description from the list announcing 
a session they wish ,o receive. The selected description is passed to the session control 
system 500 which determines which of the user's multimedia applications 520 are required 
for participation in the described session, starts the applications and mitiates and provides 
Che necessary media streams to the respective app.ictions 520 via a conjunctions 
manager 550. 



The reeving interface 510 may be linked to other tnternet communications applications 
540 such as a WWW browser or an email client (no, shown) which may be used to gather 
further information on the described session based on links provided in the session 
desenption. Also, where an incomptete se, of base and/or media modules of a session 
15 description are received, the receiving interface 5!0 attempts to obtain the remaining 
modufcs using the Interne, communications applications prior ,„ passing it onto the session 
control system 500. 



Figure 6 is a flow chart showing the steps taken by the session control system 500 upon 
20 receipt of a session description. The description is first parsed in step 600 to identify client 
applications for each media module. Once this is done a second parse is carried out where 
applications are launched in step 610, that is to say for each media module start the 
application specified in the client field if that application has not already been started. The 
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portion of the session description relating to the respective media type, i.e. the media 
module, the base module directly above the media module, all other modules attached to 
that base module and any other options modules that apply, is passed to the corresponding 
application in step 620. Since the media modules are marked with appropriate client 
applications, each application will be able to select those media streams that it wants to 
participate in. The application replies to the session control system with a connection 
request specifying its requirements in the form of a list of identifiers of media modules 
from which streams are to be initiated in step 630. The connection request is assembled by 
the session control system in step 640 and the system then parses the session description to 
identify other applications to launch in step 645. If a further media type is found, steps 610 
to 640 are repeated, otherwise the session control system uses the assembled connection 
requests to form a list of media modules. This list is passed, together with a session QoS 
policy, to the communications manager, a system used in by the session control system, 
which determines according to the QoS policies and available system resources whether 
each connection request is viable. 

The session QoS policy is constructed in two steps: 

- first, the multiple session QoS policies relevant for all the media modules to be initiated 
are combined into one session QoS policy 

- second, the resulting session QoS policy may be adapted to take account of (a) user 
default preferences (defined in a user profile), (b) a user's wish to determine the policy 
interactively, and (c) an application's default configuration (defined in the application 
profile(s)). 
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The communications manager responds to the session control system in step 650 with an 
indication of the viable media stream connection requests. If necessary, the session control 
system may contact a charging system to initiate accounting for the session prior to 
5 requesting the communications manager to create the viable media stream connections in 

step 660. 

Once a session starts, each received data stream relating to the session is passed to the 
associated multimedia application in step 670 until the scheduled stream time ends in step 
1 0 680 or the multimedia application requests to the session control system that the connection 
is terminated in step 690, at which point the session control system disconnects the 

connection in step 700. 

Figure 7 is a flow chart showing the QoS management step 650 of Figure 6 in greater 
15 detail. 

Having received the assembled list of connection requests, the communications manager 
matches each item of this list to a media profile in step 705. A media profile defines 
requirements which must be met for the requested media stream to operate on the end 
20 user's computer including the minimum network bandwidth needed for satisfactory 
reception of the stream. 



A terminal profile is determined in step 710. The terminal profile defines the 



resources 
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which are available at the end user's computer for use by the requested media streams. 
This includes available network bandwidth, free memory and disk space and available 
hardware such as monitor size, processor speed and free audio and video capture devices. 
The media profile of each connection request is compared against the available system 
resources defined by the terminal profile in step 720. If the terminal profile matches or 
exceeds the media profile, the connection request is declared viable in step 730 and the 
terminal profile is decremented accordingly for the remaining connection requests in step 
740. Each connection request is processed until there are no remaining requests or until the 
media profile of a request exceeds the terminal profile. In this situation, the 
communications manager determines the optimum terminal profile the user's computer 
would have if all non-essential applications were not running in step 750 and whether the 
computer is capable of fulfilling the media profile in step 760. If the computer is capable 
of fulfilling the media profile, the communications manager attempts to free system 
resources from currently allocated streams or connection requests which have lower 
priority or by asking the user to terminate other non-essential applications running on the 
computer in step 770. Alternatively, this could be done by reducing the number of layers 
received from a layered stream transmission. If sufficient resources cannot be found an 
exception is reported to the user and the connection request is marked as unviable. If the 
media stream that cannot be received is defined as mandatory in a QoS policy for a media 
session or subsession, all the connection requests for that media session or subsession are 
cancelled in step 790. If, however, the media stream is optional, the communications 
manager continues processing further connection requests in step 720. Once all pending 
connection requests have been processed, the communications manager reports those that 
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are viable to the session control system. 



The processing of a session description will now be described with reference to Figure 4 
and session description example 4 which is the session description generated for Track 1 
(modules 410 and 420-424 of Figure 4). 



10 



15 



20 



25 



30 



35 



40 



45 



-► 

) 

( 



# overall conference session 
type = (base) 
id =(4 10) 

info = (title = " Multimedia98 Conference ") 
source = (owner = "Joe Bloggs" email = joe@nowhere.com) 
media = (video = (client = RealPlayerG2) whiteboard = (client = wb)) 
time(start= "09:00 GMT 25/12/98" stop=" 13:00 GMT 25/12/98") 
options = (oc = 00 1 0) 

modules = (b =420 b=430 b=440 oc=411) 



# conference track 1 
type = (base) 

id = (420 410) 

info = (title="MM98 Systems and Applications Track") 
source = (owner = "Joe Bloggs" email = joe@nowhere.com) 
media=(video=(client=RealPlayerG2) whiteboard = (client =wb)) 
time(start= "09:00 GMT 25/12/98" stop- "11:00 GMT 25/12/98") 
options = (osq =424) 

modules = (m = 421 m=422 m=423 osq=424) 

# video for track 1 
type = (media) 

id = (421 420) 

info = (title = "MM98 Systems and Applications Track Video") 
source = (owner = "Joe Bloggs" email =joe@nowhere.com) 
media = (video = (type = live client = RealPlayerG2)) 
connection = (226.0.0. 100/1000) 

time = (start= "09:00 GMT 25/12/98" stop-" 11:00 GMT 25/12/98") 

# audio for track 1 
type = (media) 

id = (422 420) 

info = (title ="MM98 Systems and Applications Track Audio") 
source = (owner = "Joe Bloggs" email=joe@nowhere.com) 
media = (audio = (type = live format = g7 1 1 )) 
connection=(226.0.0. 101/1001) 

time = (start ="09:00 GMT 25/12/98" stop- "11:00 GMT 25/12/98") 



10 



15 



20 



25 



24 



( # whiteboard for track 1 
type = (media) 
~^ id=(423 420) 

info = (title="MM98 Systems and Applications Track Whiteboard") 
source = (owners "Joe Bloggs" emails joe@nowhere.com) 
media = (whiteboard = (client = wb)) 
connection=(226.0.0. 102/1002) 
^ time = (start ="09: 00 GMT 25/12/98" stop="l 1:00 GMT 25/12/98") 

( # session QoS for track 1 
type = (option-sQoS) 
-► id = (424 420) 

mandatory = (421 422) 
optional = (423) 

) 



Session description example 4 

The session control system, having received the above session description, processes the 
tree structure of the session description starting at base module 410. The first module 
encountered is base module 420. As this is not a media module but it does have sub- 
modules, the session control system continues down this branch to media module 421. 



The media field of the media module 421 already defines the multimedia client application 
required as RealPlayerG2 thus the session control system ignores it and continues to the 
next media module. The media field of the media module 422 does not have a multimedia 
client application defined, however a format for the audio data is specified. The session 
30 control system recognises that this particular audio format can be supported by 
ReaIPlayerG2 so it amends the media field to read client = RealPlayer G2. The next media 
module 423 has already defined a client application as wb so it ignores this module, and it 
also ignores the option module 424. 
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The session control system parses the tree structure again in order to launch client 
applications. The first media module 421 specifies that RealPlayerG2 should be launched, 
hence the session control system launches the application on the end user's system and 
keeps a record of this activity. The second media module 422 specifies an application that 
has already been launched and so the session control system ignores it and continues to the 
next media module. The media module 423 specifies that wb should be launched, so the 
session control system launches the application and keeps a record of this activity. 

RealPlayerG2 is passed the media module 421, base module 420 and modules 422-424. 
The application processes the media modules given to determine which it can handle, and 
in this case it identifies 421 and 422. Having determined which streams it can handle, the 
application sends a connection request back to the session control system requesting 
connection to the media streams of modules 421 and 422. Similarly, wb is passed the 
media module 423, base module 420, modules 421-422, and the module 424. The 
application process the given modules as described previously, and requesting connection 
to the media stream of modules 423. 

The above connection requests are assembled by the session control system into a list, this 
list is then passed to the communications manager along with the session QoS policy 
module 424. The communications manager determines whether each request is viable 
according to the steps of Figure 7. 
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Assuming there are sufficient resources for all the connection requests for mandatory 
media streams, the communications manager passes back a list of viable streams to the 
session control system which then processes the tree again to determine the connection data 
held in the connection field of each media module so it can request that the 
5 communications manager initiate a connection to the appropriate media stream for each of 
the viable connection requests according to the connection data. The session control system 
then manages the session and its media stream connections as is described with reference 
to steps 670 to 700 of Figure 6. 

10 The foregoing examples of the present invention have mostly been concerned with media 
session descriptions in which the client application required in order to receive a 
constituent media stream is explicitly prescribed. Session description example 1 discussed 
above is an example of a session description in which the client application is prescribed. 
If the client application is capable of accepting more than one media stream encoding 

15 format then this may also be prescribed. The session description may prescribe a blueprint 
of components, and the required configuration of the components such as interfacing and 
data passing, which the user's terminal must instantiate in order to participate in a media 
stream. The components may be, for example, for media transmission/reception, 
encryption or compression. 



20 
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An example of a session description for such an approach is shown below: 



( # Java Bean client blueprint declaration for Text chat session 
type = (media) 
id=(1030,1000) 
info=(title="Text Chat") 

source=(owner="Joe Bloggs" email=ioe@nowhere.cnm ) 
media=(Java Bean=( 

<bean class=="java.util.Vector n > 
<add> 

< bean class = "nowhere. com.chat.StringMulticastBean" id = "Multicaster" 
< property name = "debug" > 

< cast class = "boolean" > < string > false < /string > < /cast > 

< /property > 

< event-binding name = "message" > 

< script > 

<bean source = "Text Area" > 

< call-method name = "append" > 

<property target = "event :argl" name = "message"/ > 
< /call-method > 

< call-method name = "append" > 

< string > 
 < /string > 

< /call-method > 
</bean> 

< /script > 

< /event-binding > 
< /bean > 

< /add > 
<add> 

< bean class = "java.awt. Frame" > 
<property name = "title" value = "Chat"/ > 
<add> 

<bean class = "java.awt.TextArea" id= "TextArea" > 

< property name = "editable" > 

< cast class = "boolean" > 

< string > false < /string > 

< /cast > 

< /property > 
</bean> 

< string > Center < /string > 

< /add > 
<add> 

< bean class = "java.awt. Panel" id = "Panel" > 
<add> 
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<bean class = "java.awt.Button" > 
<property name = "label" value = "Clear "/ > 

< event-binding name = "action" > 

< script > 

< property target = "TextArea" name = "text" > 
< string/ > 

< /property > 

< /script > 

< /event-binding > 
</bean> 

</add> 
< /bean > 

< string > East < /string > 
</add> 
<add> 

<bean class = "java.awt. Panel" > 
<add> 

<bean class = "java.awt.TextField" id = "TextField"> 

< args > 

<cast class="int"><string>20</string> </cast> 
</args> 

</bean> 

</add> 

<add> 

< bean class = "java.awt.Button" > 
<property name = "label" value = ,, Send , 7> 

< event-binding name = "action" > 

< script > 

< bean source = "Multicaster" > 
< call-method name = "send" > 

<property target = "TextField" name= "text"/ > 

< /call-method > 

< /bean > 

<property target= "TextField" name= "text" > 

< string/ > 

< /property > 

< /script > 

< /event-binding > 
< /bean > 
</add> 

< /bean > 

< string > South < /string > 
</add> 

< /bean > 
</add> 
</bean>) 
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connection = (524 . 0.0 . 100/ 12345) 

) 

Session Description example 5 



5 However, as an alternative to the above prescriptive approaches, a media session 
description may declare the requirements in order for participation in the media stream and 
leave it to the end user's terminal to determine the client application required to participate 
in that media stream. In declaring the requirements, the session description may define the 
encoding format of the media stream and leave it to the end user's terminal to find a client 
10 application capable of handling that encoding format. Session description example 4 
discussed above is an example of this. A number of components types (e.g. video, 
encryption) may instead be declared which the user's terminal must select from those 
available to it and instantiate an appropriate application in order to participate in the 



session. 



30 

example of a session description for use in such an approach is shown below: 



( # Video client declaration 
type = (media) 
id=(1010,1000) 
info=(title="Video stream") 

source=(owner="Joe Bloggs" email=ine^)nowhere mm ) 
media=(video=(codec=mpeg width=600 height=400 depth=colour)) 
connection=(500. 1 46. 1 08.64) 
timing=(link 1020) 

) 

( # Audio client declaration 
type = (media) 
id=(l 020, 1000) 

info=(title="CD Quality Audio Stream") 
source=(owner="Joe Bloggs" emai1=inft^)nowheif».mm ) 

media=(audio=(type=(codec=RealAudio) timing=svnchroniser ticker=stock ticker)) 
source=(500. 146.107.25) _ 

) 

Session description example 6 

A session description may include a number of different types of media session 
descriptions for separate portions of the session or as alternatives to each other. 

Figure 8 is a schematic diagram of another system for managing media stream connections 
at a terminal in accordance with the present invention. The system operates in a manner 
which is similar to that which has been described with reference to Figures 5, 6 and 7. In 
particular, this example is particularly useful when a session description includes 
declarative components such as those described above. 



The session control system 800 includes a session description parser 810, an appl 



ication 
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builder 820, a number of applications and application components 830 and a 
communications manager 840. Upon receipt of a session description by the session control 
system 800, the session description parser 810 parses the session description to determine 
client application requirements for the media streams of the media session described by the 
session description. The client application requirements are passed to the application 
builder 820 which generates a number of possible application configurations based on the 
available applications and application components 830. In combination with the 
communications manager 840, the application builder evaluates each application 
configuration to determine the best configuration which is the closest match to the client 
application requirements whilst satisfying predetermined criteria such as quality of service, 
resource utilisation and user preferences. The best configuration, which may be an existing 
application instead of a combination of components, is then selected and instantiated. The 
components may include Java Beans, COM objects, MHEG objects, components from 
dynamic linked libraries or applications that are linkable to others such as the ActiveMovie 
application. 



an 



ion 



As an example, in a multimedia conference an application may be required that includes 
audio component and an encryption component. Insetad of selecting an applicat: 
requiring many resources and offering facilities such as video which are not supported by 
the conference, individual Java Bean components are combined to provide the application. 

The application builder may be configured to determine the best application configuration 
in combination with the communications manager by heuristic methods or other artificial 
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intelligence methods such as knowledge-based systems, neural networks or genetic 
programming. 



Due to the heterogeneity of the Internet and differing capabilities and operating 
environments of end user computer systems, the session control systems described above 
with reference to Figures 5 and 8 above have been implemented in Java (Java is a Trade 
Mark of Sun Microsystems Inc.). The announcement receiving interface, Session 
Directory, receives the announcements, displays them and passes those selected by the end 
user to the session control manager implemented as an application programming interface 
running as a background process on the end user's computer. 

Whilst the present invention has been described with reference to the Internet and multicast 
transmissions, it will be apparent to the reader that the described modular session 
description and the session control system are applicable to the announcement and 
^subsequent management of connections to media streams of a (multi)media session using 
other known transport mechanisms such as unicast. 

Furthermore, although mechanisms for encryption, charging and other such services have 
not been explicitly described, it would be apparent to the reader that appropriate session 
descriptions and associated functions within the session control system for their processing 
could be readily implemented according to the mechanism required. 



CLAIMS 
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1 . A method of announcing a description of a media session, comprising the steps of: 
generating a first base module containing user orientated data relating to the media session; 
generating at least one media module containing technical data necessary for a user to 
receive a media stream of the media session; 

linking the first base module to the at least one media module; and, 

announcing the media session by making at least the first base module available to potential 
recipients of the media session, 

wherein the link between the first base module and the at least one media module permits a 
party to access the at least one media module and subsequently participate in the media 
session. 

2. A method according to claim 1, further comprising the steps of: 

generating a second base module, the second base module containing user orientated data 

relating to a sub-session of the media session; 

linking the second base module to the first base module; 

generating at least one media module; and, 

linking said at least one media module to the second base module. 

3. A method according to claim 1 or 2, in which a media module prescribes the 
application to be used to participate in the media session. 
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4. A method according to any preceding claim, in which a media module prescribes a 
number of application components to be used in order to build an application to participate 
in the media session. 

5. A method according to claim 4, in which the media module prescribes a manner in 
which the components are to be configured to build the application. 

6. A method according to any preceding claim, in which a media module declares a 
number of requirements which an application or a configuration of application components 
must satisfy in order to be used to participate in the media session. 

7. A computer readable storage medium containing data defining at least a part of a 
description of a media session, the session description comprising a first base module 
containing user orientated data relating to the media session, wherein the first base module 
includes a link to at least one media module which provides technical data necessary for a 
user to receive a media stream of the media session, and wherein the link between the first 
base module and the at least one media module permits a party to access the at least one 
media module and subsequently receive the media stream. 

8. A computer readable storage medium according to claim 7, in which a media 
module prescribes the application to be used to participate in the media session. 



9. 



A computer readable storage medium according to claim 7 or 8, in which a media 



35 

module prescribes a number of application components to be used to build an application to 
participate in the media session. 

10. A computer readable storage medium according to claim 9, in which the media 
module prescribes a manner in which the components are to be configured to build the 
application. 

11. A computer readable storage medium according to any of claims 7 to 10, in which 
a media module declares a number of requirements which an application or a configuration 
of application components must satisfy in order to be used to participate in the media 
session. 

12. A method of managing media stream connections for a media session, having 
obtained a session description of the media session at a terminal, comprising the steps of: 
parsing the session description using a terminal session control system to determine one or 
more applications for the or each media stream of the session description needed to support 
the media session; 

selecting one or more media streams identified in the session description; and, 
subsequently initiating the one or more media streams so that the or each media stream can 
subsequently be received by the terminal, wherein the session control system manages the 
connections required to participate in the media session. 

13. A method according to claim 12, in which the applications select one or more of 
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the media streams identified in the session description which are required and pass a 
number of connection requests to the session control system. 

14. A method according to claim 12, in which the step of parsing the session 
5 description includes the steps of determining application configurations to satisfy 

requirements identified in the session description to participate in the media session. 

15. A method according to claim 14, in which the terminal session control system 
parses the session description and passes at least a portion of the session description to an 

10 application builder for determining the application configurations 

16. A method according to claim 15, in which the application builder builds the 
application(s) necessary to participate in the media session. 

15 17. A method according to claim 16, in which the application builder generates or 
modifies a quality of service policy for the connection request for use by the terminal 
session control system. 

18. A method according to claim 16, in which the application builder modifies the 
20 session description for changing the subsequent management of connections by the terminal 

session control system. 

19. A method according to any of claims 16 to 18, in which the application is built 
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from a number of application components. 

20. A method according to any of claims 12 to 19, in which the session description is 
announced in accordance with the method of any of claims 1 to 6. 

5 

21. A system for managing media stream connections derived from a session description 
of a media session, comprising a session control system for parsing the session description to 
determine one or more applications for the or each media stream of the session description 
needed to support the media session, the session control system being arranged to manage 

10 connections required to receive the one or more appropriate media streams of the media 
session. 

22. A system according to claim 21, in which the session control system further 
comprises means for determining application configurations to satisfy requirements 

15 identified in the session description to participate in the media session. 

23. A system according to claim 22, further comprising a number of application 
components from which the application configurations are determined and from which the 
applications are built. 

20 

24. A system according to claim 23, in which an application builder builds the 
applications. 
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25. A computer readable storage medium containing executable instructions for 
performing the method of any of claims 1 to 6 or 12 to 20. 

24. A computer readable storage medium containing the system according to any of 
5 claims 7 to 11 or 21 to 24. 
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